home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 2 / CU Amiga Magazine's Super CD-ROM 02 (1996)(EMAP Images)(GB)[!][issue 1996-04].iso / magazine / amiga_e / amigae.june.archive / 000032_crash!kirk.safb.af.mil!BWILLS_Wed, 9 Jun 93 00:06:40 PST.msg < prev    next >
Text File  |  1993-08-31  |  4KB  |  111 lines
  1. Received: by bkhouse.cts.com (V1.16/Amiga)
  2.     id AA00000; Wed, 9 Jun 93 00:06:40 PST
  3. Received: from kirk.safb.af.mil by crash.cts.com with smtp
  4.     (Smail3.1.28.1 #15) id m0o3H4K-0002yBC; Tue, 8 Jun 93 20:43 PDT
  5. Message-Id: <m0o3H4K-0002yBC@crash.cts.com>
  6. Date: 8 Jun 93 22:41:00 CST
  7. From: "Barry D. Wills" <BWILLS@kirk.safb.af.mil>
  8. To: "amigae" <amigae@bkhouse.cts.com>
  9. Subject: re (renamed):  faster EPP
  10.  
  11. Subj:   Re (renamed):  faster EPP
  12.  
  13. Son Le, good to hear from you again.
  14.  
  15. [starting with your quote:]
  16.  
  17. >>>Read() is just slightly slower than Fgets() (;
  18. >>
  19. >> I'll  use it.  When I get 2.1 I can start supporting both OSs.  'til then you
  20. >> should have little trouble plugging in the read() function from V0.10b and
  21. >> replacing Read() with Fgets().  BTW, why the difference in speed?  This could
  22. >> be crucial since I'm basically reading into a buffer and copying part of the
  23. >> buffer to a string variable.  That extra step takes some time.
  24. >
  25. >Actually, after examining epp013b and doing a bit more testing, I must say that
  26. >your method is almost(!?) as fast as Fgets() _if_ you increase the buffer et al
  27. >to max.. Then epp013b is slower by about half a second, processing epp.e.
  28. >Must be the extra passing and parsing. Also, since E doesn't registerise
  29. >procedure variables, sometimes it's slower (although still smaller) than
  30. >optimised C code. For max speed, use assembly..
  31.  
  32. Well, a maximum 1024-byte buffer seemed good to me at first, but I have seen
  33. the error of my ways.  EPP 0.14b will be out in a few days, and the max
  34. input file buffer constraint will be removed.  I modified the code and tried
  35. to break it, but it stood, so it looks like those with enough ram will be
  36. able to set a buffer size to accommodate their largest file.
  37.  
  38. >
  39. >[....]
  40. >
  41. >Yep, it's fixed. Btw: can you change your parsing routine to accept main() and
  42. >not "main ()".. it's looks wrong. (;
  43.  
  44. Will do.  Sorry about that, I suppose I'll be ironing out my coding habits
  45. for some time.
  46.  
  47. >> I can sympathize.  What kind of system are you running?  I'm using a
  48. >> Deringer-030, 25MHz w/32-bit RAM, and it breezes through most things, but when
  49. >> I stepped down to test EPP on the 68000 it was physically distressing!
  50. >
  51. >Amiga 2000 with 105 meg GVP series II - plain 68000. Now you know how I feel!
  52.  
  53. How much ram?  Will the removal of that constraint help you?  What kind of
  54. times are you getting?
  55.  
  56. >On the subject of your sources (or anyone's for that matter) post them!
  57. >The more sources, the merrier and the more we can learn!
  58. >
  59. >(To Norman Kraft, sorry Barry, how do we post sources? UUencode 
  60. From crash!kirk.safb.af.mil!BWILLS Wed, 9 Jun 93 00:06:43 PST
  61. Received: by bkhouse.cts.com (V1.16/Amiga)
  62.     id AA00000; Wed, 9 Jun 93 00:06:43 PST
  63. Received: from kirk.safb.af.mil by crash.cts.com with smtp
  64.     (Smail3.1.28.1 #15) id m0o3H6d-0000SmC; Tue, 8 Jun 93 20:45 PDT
  65. Message-Id: <m0o3H6d-0000SmC@crash.cts.com>
  66. Date: 8 Jun 93 22:41:00 CST
  67. From: "Barry D. Wills" <BWILLS@kirk.safb.af.mil>
  68. To: "amigae" <amigae@bkhouse.cts.com>
  69. Subject: re:  E, C, and bobs
  70.  
  71. Subj:   re:  E, C and bobs
  72.  
  73. Hi, Peter, good to hear from you again.
  74.  
  75. >However I have this european thing from the International Amiga C Club
  76. >that explains everything about amiga in C. Mine is version 2.0 and I know
  77. >they released newer versions. Mine is 4 disks which have tutorials and
  78. >source in C.
  79.  
  80. Thanks for the info.
  81.  
  82. >C give me a headache. I love E but I can't do the simple things in the
  83. >TEACH YOURSELF C book in E.
  84.  
  85. Send me some of your C code from TEACH YOURSELF C and I'll try to translate
  86. it.
  87.  
  88. >I try stupid Text processing garbage like
  89. >
  90. >Ask for input (a character)
  91. >
  92. >Tell user that <character> in ascii is <asciinumber>
  93. >
  94. >Ask for any input to continue or Q to quit.
  95. >
  96. >Problem is, after one FgetC()
  97. >any other FgetC gets skipped over and a blank and <CR> gets put in it's
  98. >place.
  99.  
  100. Looks like our messages are passing each other on the net.  By now you should
  101. have gotten my message treating your a:=Inp(stdout) problem.  You can use
  102. the same solution for FgetC().
  103.  
  104. >I also only have E 2.1 not 2.1b :-(
  105.  
  106. Are you having trouble finding 2.1b?  Hang in there.  Wouldn't want you hang
  107. up on E.  It's a pretty awesome language.  I'm serious when I say that you
  108. should send some C code.  I'll see what I can do with it, and I'm sure some
  109. others on the list would enjoy the exercise.  Talk to you later.
  110.  
  111. -- Barry